A networked storage system may include one or more storage servers, which may be storage appliances. A storage server may provide services related to the organization of data on mass storage devices, such as disks. Some of these storage servers are commonly referred to as filers or file servers. An example of such a storage server is any of the Filer products made by Network Appliance, Inc. in Sunnyvale, Calif. The storage appliance may be implemented with a special-purpose computer or a general-purpose computer. Depending on the application, various networked storage systems may include different numbers of storage servers.
In a conventional networked storage system, log replay is commonly performed to recover from a failure or a fault in the storage server. The operating system of the storage server maintains a log of operations of transactions such as write operations directed to the mass storage devices that have to be replayed or re-executed in a local non-volatile storage device. Thus, the log may be referred to as an “nvlog.” However, the replay is usually slow, because the operations are replayed serially in the same order as they had been stored in the log, and each operation may use data that has to be fetched from multiple mass storage devices or an internal memory of the storage server. Many of the accesses to the mass storage devices incur high latency.
One existing approach to solving the above problem is to issue loads of transactions in parallel for a large number of replay operations, such as two hundred loads. Then the operations are replayed serially. This approach makes more efficient use of spindle resources in the mass storage devices (e.g., disks) by queuing large numbers of input/output requests to the mass storage devices at once and reduces the latency per operation. However, a significant amount of time is still wasted in fetching and loading data used by the operations. An alternative approach towards speeding up log replay is to parallelize the load operations of transactions in the log. This approach is much more complex because of dependencies amongst the transactions.